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SHARING THE PERSONAL INFORMATION OF A NETWORK USER WITH THE 
RESOURCES ACCESSED BY THAT NETWORK USER 

RELATED APPLICATIONS 

This application is related to U.S. Provisional Application No. 60/160,874, filed 

October 22, 1999 and entitled "Sharing A User ! s Personal Information," which application is 
incorporated by reference in its entirety. 

TECHNICAL FIELD 

This application relates to sharing a user's personal information — for example, 
personal preference information — with a third party in a networked computing environment. 

BACKGROUND 

The computer system 100 illustrated in Fig. 1 represents a typical hardware setup for 
executing software that allows users to perform tasks such as communicating with other 
computer users, accessing various computer resources, and viewing, creating, or otherwise 
manipulating electronic content - that is, any combination of text, images, movies, music or 
other sound, animations, 3D virtual worlds, and links to other objects. The system includes 
various input/output (I/O) devices (mouse 103, keyboard 105, display 107) and a general 
purpose computer 100 having a central processor unit (CPU) 121, an I/O unit 117, and a 
memory 109 that stores data and various programs such as an operating system 111, and one 
or more application programs 113. The computer system 100 also typically includes some 
sort of communications card or device 123 (e.g., a modem or network adapter) for 
exchanging data with a network 127 via a communications link 125 (e.g., a telephone line). 
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As shown in Fig. 2, a user of a computer system can access electronic content or other 
resources either stored locally at the user's own client system 202 (for example, a personal or 
laptop computer) or remotely at one or more server systems 200. An example of a server 
system is a host computer that provides subscribers with online computer services such as e- 
mail, e-commerce, chat rooms, Internet access, electronic newspapers and magazines, etc. 
Users of a host computer's online services typically communicate with one or more central 
servers systems 200 through client software executing on their respective client systems 202. 

In practice, a server system 200 typically will not be a single monolithic entity but 
rather will be a network of interconnected server computers, possibly physically dispersed 
from each other, each dedicated to its own set of duties an/or to a particular geographic 
region. In such a case, the individual servers are connected by a network of communication 
links, in known fashion. 

A "browser" is an example of client software that enables users to access and view 
electronic content stored either locally or remotely, such as in a network environment (local 
area network (LAN), intranet, and wide area network (WAN) such as the Internet). A 
browser typically is used for displaying documents described in Hypertext Markup Language 
(HTML) and stored on servers connected to a network, e.g., the Internet. Technically, a web 
browser is a client program that uses the Hypertext Transfer Protocol (HTTP) to make 
requests of web servers throughout the Internet on behalf of the browser user. A web server 
contains, in addition to the HTML and other files it can serve, an HTTP server daemon, 
which is a program designed to wait for HTTP requests and handle those requests when 
received. 

Fig. 3 is a screenshot of a browser application 300 (Netscape Navigator) displaying a 

typical HTML document, or web page 302. As shown therein, a single web page 302 may be 

3 
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composed of several different files potentially of different data types 304 (for example, text, 
graphics, images, virtual worlds, sounds, movies, etc.). In addition, a web page can include 
links 306 pointing to other resources (for example, web pages or individual files) available 
on the network. Links 306 can take virtually any visual form, for example, they can appear 
either as a text string or as a graphical image or a combination thereof. Each link 306 has an 
associated URL pointing to a location on the network. When a user "clicks on" or otherwise 
selects a displayed link 306, the browser automatically will retrieve a web page or other 
resource corresponding to the link's associated URL and display it to, or execute it for, the 
user. 

A user instructs a browser to access an HTML document, or webpage, by specifying a 
network address, or Uniform Resource Locator (URL), at which a desired document resides. 
URLs are defined in Internet standard RFC 1738 to include an indication of the protocol to 
be used and the location of a resource on a web server. In response, the browser contacts the 
corresponding server hosting the requested webpage, retrieves the one or more files that 
make up the webpage, and then displays the webpage in a window on the user's computer 
screen. 

Web pages typically are transported using the HyperText Transfer Protocol (HTTP) 
as defined in Internet standard RFC 2068. HTTP is a set of rules for exchanging files (text, 
graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative 
to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols (which are 
the basis for information exchange on the Internet), HTTP is an application layer protocol. 

When a user of a web browser sends an HTTP request by typing in a URL or clicking 
on a hypertext link, the browser builds an HTTP request and sends it to the address indicated 
by the URL. The HTTP server daemon in the destination server machine receives the request 
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and, after any necessary processing, the requested file is returned. The response is sent back 
to the browser where it can be displayed to the user. The HTTP protocol response includes 
various codes detailing the result of the request. For example, return code 404 indicates that 
the information requested was not found. For transactions requiring security, the HTTP 
connection can be secured with encryption. This variant is known as Secure HTTP (HTTPS) 
or Secure Socket Layer (SSL). 

HTTPS (Secure Hypertext Transfer Protocol) is a web protocol developed by 
Netscape Inc. of Mountain View, California and implemented in several browsers. The 
HTTPS protocol encrypts and decrypts user page requests as well as the pages that are 
returned by the web server. HTTPS uses Netscape's Secure Socket Layer (SSL) as a sublayer 
under its regular HTTP application layer. HTTPS uses port 443 instead of HTTP port 80 in 
its interactions with the lower layer, TCP/IP. SSL uses a key size of a predetermined number 
of bits (typically between 40 and 128) for the RC4 stream encryption algorithm, which is 
considered a minimal degree of encryption for commercial exchange. 

When visiting an electronic commerce merchant, a user typically is presented with a 
web page order form URL that starts with "https://", indicating the use of the HTTPS 
protocol. When sending the response, the browser will use the HTTPS layer for encryption. 
The acknowledgement received from the server also will travel in encrypted form using 
HTTPS, and will be decrypted by the browser's HTTPS layer. 

HTTPS and SSL support the use of X.509 digital certificates from the server so that, 

if necessary, a user can authenticate (i.e., confirm the identity of) the sender. SSL is an open, 

nonproprietary protocol that Netscape has proposed as a standard to the World Wide Web 

Consortium (W3C). HTTPS is not to be confused with SHTTP, a security-enhanced version 

of HTTP developed and proposed as a standard by EIT. 

5 
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A digital certificate is an electronic token that establishes the credentials of a party 
doing business or other transactions on the web. Certificates are issued by a certification 
authority (CA). Typically, certificates contain a party's name, a serial number, expiration 
dates, a copy of the certificate holder's public key (used for encrypting and decrypting 
messages and digital signatures), and the digital signature of the certificate-issuing authority 
so that a recipient can verify that the certificate is real. Some digital certificates conform to a 
standard, X.509. Digital certificates can be kept in registries so authenticated users can look 
up other users' public keys. 

HTTP also includes a mechanism referred to as a "cookie," which is used for 
maintaining client side persistent data. A cookie is a token, for example, a special text file, 
that a web site stores on a user's hard disk so that the web site can remember something 
about a user at a later time. Typically, a cookie records a user's preferences when using a 
particular site. Under HTTP, each request for a web page is independent of all previous 
requests. For this reason, a web page server has no memory of what pages it has sent to a 
user previously or anything about that user's previous visits. The cookie mechanism allows 
the server to store its own file on the user's own computer. The file is typically stored in a 
subdirectory of the directory used to install the browser software. The cookie subdirectory 
will contain cookie files for each web site visited by the user that uses cookies. Cookies are 
commonly used to keep track of which banner ads a user already has encountered. This 
allows web sites to rotate the banner ads sent and thereby minimize repetition as the user 
browses through multiple pages on a site. Cookies also can be used to customize web pages 
based on a user's browser type or other information provided to the web site. Web users must 
agree to let cookies be saved on their computers by configuring their browsers to accept 
cookies. 
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Consumers can buy and sell products and services shown on web pages via electronic 
commerce ("e-commerce") transactions. To enable these transactions, a consumer and 
merchant must exchange personal and financial information concerning the online 
transaction, such as their credit card, billing address and shipping address. Conventional 
payment systems associated with many Internet commerce sites therefore require customers 
to type their credit card and mailing information into an HTML form. 

Figs. 4A and 4B show an example of an e-commerce form 400. The information from 
the form 400 typically includes name 405, shipping address 410, billing address 415, and 
credit card number 420. This information is submitted to the merchant, who then uses the 
information to complete the transaction using various known fulfillment and delivery 
mechanisms. 

Navigating and completing these forms involves a great deal of repetition and 
associated inconvenience to users when providing name, shipping address, billing address, 
and credit card data to merchants. Completing electronic forms often is a tedious and error- 
prone process. Furthermore, using these payment systems, customers visiting several online 
stores must re-enter their payment/address information at each store where they make a 
purchase, many stores even requiring shoppers to re-enter their payment information on each 
subsequent visit. 

To facilitate the process of filling out forms, "form fillers" have been developed. 
These applications automate the filling of forms encountered when visiting web sites. The 
form filler recognizes forms in HTML and records the data entered in the fields when the 
user fills out the form for the first time. Then, when similar fields show up in subsequent 
forms, the form filler can use the recorded data to automatically fill out these fields. An 
example of such a form filler is built into Microsoft Internet Explorer 5.0. Figs. 5 A, 5B, and 
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5C show a form filler application built into a browser automatically filling out the fields in an 
e-commerce form. Some form fillers further allow the user to maintain several "identities" to 
help protect privacy. Each identity keeps track of a separate set of form data that will be used 
to fill in new forms. 

5 A similar but more sophisticated approach to facilitating online transactions is the 

digital wallet. A digital wallet is a software application that allows the user to input shipping 
and billing data once and reuse this information at many different web sites to complete a 
purchase. Digital wallets that fill merchant forms or directly transfer data to merchants have 
been successfully built into browsers in several ways, including as helper applications to 
Cf 0 browsers, stand-alone applications, and browser plug-ins. 

•II Once the digital wallet is set up, the user can store, manipulate, and pay for Internet 

0 J purchases with various types of payment instruments (e.g., credit cards or electronic cash). 

Client-based personal electronic wallets have been developed to relieve this burden. 

q Client-based wallets store e-commerce information for a particular user at the machine 

operated by that user. When that machine interfaces a merchant website through the internet, 

! ** e-commerce information stored in the local wallet may be transferred to the merchant. 

However, because client-based wallets reside on the user machine, these wallets are subject 
to the limitations of the machine upon which they reside. For instance, security attacks on 
the user machine may be used to target the wallets residing thereon. In addition, limitations 

20 on portability for the machine result in limitations for the wallet. 

SUMMARY 
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One or more of the following advantages may be provided. The techniques and 
methods described here may enable the user to drastically reduce the amount of work 
required to fill out forms on web pages. This may be accomplished in one or more of the 
following ways. First, multiple pages of content can be filled out without requiring the user 
to view each page. Presenting only those fields and forms that are not automatically 
completed minimizes the work for users. Users can be selectively queried for any merchant- 
specific missing fields, thus optimizing the form filling process. Users need not inspect each 
form and approve its contents. Further, merchants using the techniques and methods 
described here may be able to provide information that is tailored and customized for the 
user, thus increasing the usefulness of the merchant's content to the user. 

Other advantages for the user include ease of use in that no additional software is 
required. Further, as the user is not tied to a single computer, the other benefits described 
here can be realized from any computer capable of accessing the merchant's site, regardless 
of its location. In addition, the user gains some security, as the invention reduces the risks 
associated with data sniffing on the user's local area network and accessing storage devices 
attached to the user's computer. 

For the merchant, the techniques and methods presented here enable merchant to 
access specific information about a customer's preferences and history. The merchant can 
use that information to customize the content presented. Merchants can track completed 
purchases in order to better handle service and information requests. Because the merchants 
can access the information using a well-defined protocol, merchants can easily modify forms 
without causing problems with many different types of software. Merchants can obtain 
demographic data for future targeted advertising. An intimate relationship between the 
merchant, the user, and the online service is fostered. 
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These techniques and methods can be generalized and applied to any type of data 
(e.g., travel preferences), in addition to shipping, billing, and demographic data. In addition, 
they may be implemented using a system, method, software, or some combination thereof. 

Details of one or more implementations are set forth in the accompanying drawings 
and the description below. Other features and advantages will be apparent from the 
description and drawings, and from the claims. 



DESCRIPTION OF DRAWINGS 

Fig. 1 shows a block diagram of a computer system. 

Fig. 2 shows a typical network-computing environment. 

Fig. 3 shows a browser application displaying a typical web page. 

Fig. 4A shows a browser displaying an e-commerce form. 

Fig. 4B shows the second page of the e-commerce form of Fig. 4A. 

Fig. 5 A shows exemplary results of using a form filler application. 

Fig. 5B shows the second page of exemplary results of Fig. 5 A. 

Fig. 5C shows the third page of exemplary results of Fig. 5 A. 

Fig. 6 is a host-to-host architecture for sharing e-commerce transaction information. 

Fig. 7A shows an authentication process. 

Fig. 7B shows the process for requesting purchase information. 

Fig. 7C shows the process for requesting credit card numbers. 

10 
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Fig. 8 is a flowchart of the typical sequence of screens displayed to users. 

Fig. 9 is a screenshot of a merchant's product ordering page. 

Fig. 10 is a screenshot of the framework authentication page. 

Fig. 1 1 A is a screenshot of the framework registration page. 

Fig. 1 IB is the second page of the screenshot of Fig. 12A. 

Fig. 12 is a screenshot of the merchant's order confirmation page. 

Fig. 13 is a screenshot of the framework edit preferences page. 

Fig. 14 is a screenshot of the framework edit credit cards page. 

Fig. 15 is a screenshot of the framework edit addresses page. 

Fig. 16 is a screenshot of the framework change security page. 

Fig. 17 is a screenshot of the framework delete preferences page. 

Fig. 18 is a screenshot of the framework customer service page. 

Fig. 19 is a screenshot of the merchant's choose addresses page. 

Fig. 20 is a screenshot of the merchant's order information page. 

Like reference symbols in the various drawings may indicate like elements. 



DETAILED DESCRIPTION 



Quick checkout (QC) is a host-based system for sharing personal information of a 
network user with the resources accessed by that network user. QC generally involves either 

11 
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or both of two data stores, referred to as passport and wallet. Passport and wallet are host- 
based collections of routinely requested personal billing, shipping and demographics 
information (hereinafter "personal information")- They may be maintained independently or 
collectively. A user with a populated passport or wallet may choose to pass selected 
information to web sites, automatically or with very little effort, to enable an enhanced 
browsing experience or to assist in the completion of an online transaction. 

For instance, when merchants offer QC as a payment option and the consumer elects 
to invoke QC, the merchant simply passes the order information to a pre-determined SSL- 
enabled QC form that is then displayed to the consumer. Payment information and shipping 
address are sent from the QC database to the QC form, and the form is confirmed, rejected or 
modified by the consumer. In this manner, the consumer need not redundantly enter payment 
information for each transaction or each merchant. Rather, they may rely on the wallet for 
this information, merely confirming its accuracy. As will be explained in greater detail 
below, when the wallet includes several options for payment, shipping, etc., the consumer 
may establish default information, and has the ability to select desired information from 
among that stored. 

This host-based system facilitates seemless integration with other merchant services 
as well as the surrounding wallet/passport provider environment. Because the wallet and 
passport are host-based, they are inherently portable, updateable, secure and simple to setup 
and use. 

QC can be used to share many different pieces of a user's personal information, 
before and during an e-commerce transaction. For instance, using QC, selected user 
information may be shared with merchant servers upon user's access to their web sites or 
later when performing an e-commerce transaction. More specifically, upon access to a 

12 
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merchant's web site, it is possible to share personal information to enable the merchant to 
personalize the content and services provided to the user. In this sense, QC can share 
virtually any other type of personal information, such as travel preferences, demographic 
information, food choices, and medical information. Thereafter, upon checkout, it is possible 
to share personal information of a more specific nature, generally concerning e-commerce 
information. For instance, commercial information such as user name, address, and credit 
card information can be shared when appropriate to further e-commerce transactions. Each 
user's information is stored in a "profile" that can be updated frequently. This information 
can be stored in any proprietary or commercially available relational or object database 
management system (DBMS), such as provided by Oracle, Inc. or Informix, Inc. 

Fig. 6 shows one potential architecture of the framework, known as a "host-to-host" 
architecture. This architecture leaves the client computer 601 unmodified. The client 
computer 601, network host 602, and the preferences server 603 can communicate with each 
other to exchange user preferences information efficiently with a minimum of user 
interaction. Once the preferences server 603 authenticates the user, the network host 602 can 
directly communicate with the preferences server 603. 

HTTPS is generally used as a transport for requests and responses; however, other 
protocols could also be used as transport mechanisms. Input parameters in requests and 
return values must be URL-encoded, to ensure that nonstandard characters are properly 
transmitted over the Internet. Furthermore, return codes from the requests may be used to 
verify their success. 

Although the framework does not require a fixed sequence of requests from network 

hosts, communications between the user, the merchant, and the framework typically follow a 

particular pattern, illustrated in Figs. 7 and 7 A, 7B, and 7C. The basic pattern is to 

13 
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authenticate the user 710, request purchase information 720, request payment information 
73 0, and finally to place the order 740. Each of these steps is described further below with 
respect to Figs. 7A-7C, which shows client computer 701, merchant web server 702, 
preferences server 703, preferences database 704 and network 705. 

Fig. 7 A shows the exchange of messages between the user, merchant, and the 
framework server during the authentication step 710. First, in step 710a, the merchant web 
server 702 provides a browser at client computer 701 access to its web page. The user is able 
to view the web page and select a set of products or services offered by the merchant, and 
thereafter may invoke "QuickCheckout" to proceed with an e-commerce purchase. When 
QuickCheckout is invoked 710a, an authentication request 710b is sent to the preferences 
server 703 for authentication. After the user enters an authorized username and password, a 
session identifier is generated 710c and returned by the preferences server 703, and the user's 
browser 701 is again directed to a web page on the merchant server 702. The session 
identifier is then sent 710d to the merchant, e.g., in the form of a cookie. For authentication 
throughout the remainder of the session, this session identifier will be sent with each 
communication by the merchant server 702 to the preferences server 703 during the session. 

Fig. 7B shows the exchange of messages that occurs while getting purchase 

information to the merchant server 702, according to step 720. In step 720a, immediately 

after receiving an authentication confirmation from step 710, the merchant server 702 sends 

the session identifier with a request sent to the preferences server 703 for information about 

the user. The merchant server 702 also sends an X.509 SSL server certificate and a set of 

merchant preferences in the authentication request of step 720a. This certificate is used by 

the preferences server 703 to verify the identity of the merchant server 702 initiating the 

request for information. The preferences requested by the merchant server 702 of the 

14 
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preferences server 703 will be used to tailor later content and services provided by the 
merchant server 702 to the client computer 701. 

In step 720b, preferences information about the user is returned by the preferences 
server 703 to the merchant server 702. In step 720c, the information is formatted into a web 
page requesting confirmation of the information from the user at client computer 701 . At this 
stage, only a portion of any previously entered credit card information is returned for security 
purposes, the returned information providing enough information for the user to confiim 
and/or edit the user information at this stage. 

Referring to Fig. 7C, the process 730 of obtaining payment information is described. 
At step 730a, once the preferences information is confirmed by the user, the merchant server 

702 sends the session identifier with a request for full payment information to the prefernces 
server 702. The user's full credit card information is then returned to the merchant server 702 
in step 730b. If the merchant server 702 does not receive the information, it 702 can check 
the HTTP return status code and take appropriate action. Otherwise, once payment 
information is received by the merchant server 702, the transaction 853 may be processed 
with the credit card company in step 730c, and wait for authorization. The preferences server 

703 may also process the payment information with the credit card company. 

Finally, in step 740, the results of this transaction are sent to preferences server 703 
for customer service, record keeping, and order tracking purposes. These results are stored in 
the database for use in future transactions. The merchant can check the HTTP return status 
code from the preferences server 703 and take appropriate action if a failure occurs. 



15 
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The flowchart of Fig. 8 shows primary paths involved in a typical transaction. The 
process also includes appropriate error handling and alternative entry points when necessary. 
The sequence of screens from the user's perspective is shown in Figs. 9-20. 

The first step 901 in the process of Fig. 8 is for the user to browse the merchant's site 
and select some items for purchase. Fig. 9 shows such a screen with some products 1001 
selected for purchase. From this page, the user clicks the "AOL Quick Checkout" button 
1002. This button initiates the authentication request described above. 

The next step 902 in the process of Fig. 8 is to show the user the authentication page 
from the AOL site. This page is shown in Fig. 10. If the user has an AOL account, he enters 
his screen name 1 101 and password 1 102, then clicks on the "OK" button 1 103. If the user 
does not have an AOL account, then the user can register by clicking on the "Signup Now!" 
button 1 104. The registration step 903 in the process of Fig. 8 involves filling out a form, 
shown in Figs. 1 1 A and 1 IB. The form contains credit card information 1201, shipping 
information 1202, and account information 1203. After entering the required information, the 
user can register by clicking the "OK" button 1204. 

Once the user has either successfully authenticated or registered, the next step 904 in 

the process of Fig. 8 is to show the user a web page allowing him to review the order. Fig. 12 

shows how this page details the order 1301 and shows the default transaction information 

1302 provided by the framework server to the merchant. Only the last four digits of any 

credit card number 1303 are provided at this stage. From this screen, the user can choose 

shipping addresses by clicking on the "Choose Shipping Addresses" button 1304. The user 

can also choose to edit the transaction information by clicking on the "Edit Information" 

button 1305. When the user is satisfied with the addresses and transaction information, he 

can click on the "Complete AOL Quick Checkout" button 1306 to confirm the transaction. 

16 
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By confirming the transaction, the user is authorizing the merchant to complete the 
transaction with the credit card company using the information displayed. 

If the user chooses to edit transaction information, the next step 905 in the process of 
Fig. 8 is to show the user a set of edit screens. The first such screen is shown in Fig. 13 and 
allows the user to edit credit cards 1401, edit shipping addresses 1402, change security 
information 1403, delete AOL Quick Checkout settings 1404, and request customer service 
1405. Once the user makes a selection, the appropriate screen is displayed. 

If in step 905 the user chooses to edit credit cards, the next step 906 in the process of 
Fig. 9 is to display the screen shown in Fig. 14. This screen allows users to select a credit 
card for use in the current transaction by selecting one of their currently defined credit cards 
1501 and clicking the "Use This Card" button 1502. Users can also edit a credit card's 
information by clicking the "Edit This Card" button 1503. To edit a card or add information 
about a new credit card, the user can fill in the fields in the lower portion of the screen 1504. 
When the user is finished editing, he can click the "Add This Card" button 1505 to add the 
information to their profile. 

If in step 905 the user chooses to edit addresses, the process is very similar to that for 
editing credit cards. The next step 907 in the process of Fig. 9 is to display the screen shown 
in Fig. 16. This screen allows users to select a shipping address for use in the current 
transaction by selecting one of the currently defined shipping addresses 1601 and clicking the 
"Use This Address" button 1602. Users can also edit an address by clicking the "Edit This 
Address" button 1603. To edit an address or add a new address, the user can fill in the fields 
in the lower portion of the screen 1604. When the user is done editing, he can click the "Add 
This Address" button 1605 to add the information to the profile. 

17 
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If in step 905 of Fig. 8 the user chooses to change security information, the next step 
908 in the process of Fig. 8 is to display the screen shown in Fig. 16. This screen allows a 
user to enter 1701 and confirm 1702 a new password by typing it into a form. A user can also 
change the email address 1703 associated with his profile. When the user is done editing, he 
can click the "OK" button to confirm the changes and continue. 

If in step 905 of Fig. 8 the user chooses to delete AOL Quick Checkout settings, the 
next step 909 in the process of Fig. 8 is to display the screen shown in Fig. 17. This screen 
asks a user to confirm that he wants to delete all of his credit card and shipping address 
information stored in the profile. A user can confirm this desire by clicking on the "Yes" 
button 1801. 

If in step 905 of Fig. 8 the user requests customer service, the next step 910 in the 
process of Fig. 8 is to display the screen shown in Fig. 18. This screen displays customer 
service information 1901 for all the companies associated with the AOL Quick Checkout 
service. This screen also offers additional information about the AOL Quick Checkout 
service 1902. 

If the user in step 904 of Fig. 8 decides to choose addresses instead of editing 
preferences, the next step 91 1 in the process of Fig. 8 is to display the screen shown in Fig. 
19. This screen shows the products 2001 selected by the user for purchase. The user can 
assign one of the addresses 2003 to each product by selecting the appropriate number in the 
pulldown menu 2002. Once the user has finished selecting addresses, he can finalize his 
choices by clicking on the "Use These Addresses" button 2004. In addition, the user can edit 
addresses, as discussed above in step 907 of Fig. 8, by clicking the "Edit Addresses" button 
2005. 
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If the user in step 904 of Fig. 8 is satisfied with the transaction selections, and has 
clicked the button 1306 to complete the transaction, the next step 912 in the process of Fig. 8 
is to display a final page verifying that the transaction has been completed. This screen, as 
shown in Fig. 20, displays the transaction information 2101 that was used by the merchant to 
complete the credit card purchase. The display may include a confirmation string 2102 or 
order identification string 2103 for record keeping purposes. 

Fig. 21 shows an implementation as part of the AOL infrastructure. The figure shows 
the host-to-host architecture, as described above, with the addition of a proxy 2202. The 
proxy acts as an intermediary for all traffic between the host service computers and the 
Internet. The proxy performs load balancing by switching connections to the least utilized 
hardware to ensure that a high degree of performance is maintained. The proxy also contains 
a list of hosts that can be redirected to internal AOL sites. The internal sites provide AOL 
users with a more consistent look and feel. The internal sites can also be more tightly 
integrated with the AOL system because they are under AOL control 

In another implementation, as users select all of the items they wish to purchase from 
a particular merchant, the merchant collects and stores information about the purchase order, 
designated with an order identifier that is used to unify the order information. The order 
information is typically presented to the consumer in a shopping cart upon request or at 
checkout. Using this order information, the consumer can confirm the contents of their 
shopping cart by invocation of QC or otherwise, as the order identifier ties any subsequent 
QC information to the order information stored by the merchant. 

Then, when the consumer launches QC using an icon at the merchant website, the 

merchant authenticates the consumer as a QC user. To do so, the merchant directs users to 

the AQC aolqc_auth url for authentication. If the GET to this url returns successfully, the 
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merchant can be assured that the user has been appropriately identified and "logged in" as an 
AQC member. For example, the GET returns with a session identifier (aolqc_session_id) 
which serves as a key to the consumer account. Thereafter, the session id is passed with 
virtually every backend call made by the merchant thereafter (e.g., to retrieve billing 
information for the customer, to enable editing by the customer). After the consumer is 
authenticated once by a merchant, they will not be redirected back to the authentication page 
until they have logged off of the AOL service. 

If authenticated, payment and shipping information is collected from QC. Preferably, 
the merchant makes a host-to-host call to fetch a "pretty print" user-displayable version of 
the user's default billing and shipping information from the QC, which version does not 
include all of the information. The merchant then automatically produces a form that 
includes order id and that is posted to https://payment.aol.com/placeorder . For instance, a 
standard form might include the parameters listed in Appendix A (see parameters spanning 
pp 5-6 of AOL QC Merchant Connectivity Specification filed with provisional application 
number 60/160,874 filed October 22, 1999, which is incorporated by reference in its 
entirety). Using the order_allow_multi_shipto field of the placeholder form, it is possible for 
a merchant to enable designation of different shipping destinations for different aspects of the 
order (e.g., per unit or per item). Similarly, other fields may be duplicated to provide 
flexibility, as needed. 

In response to the placeorder form, available QC information is returned from the 
wallet and is posted at the merchant. Default QC information may be automatically selected 
to eliminate the need for additional user interaction (unless editing is necessary). 
Alternatively, the consumer may be required to select among available QC information (e.g., 
credit card, shipping address information). In either case, a subset of the sensitive QC 
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information from the wallet is provided to the merchant in response to the placeorder request. 
This subset includes enough for consumer to confirm/select, but intentionally omits some 
information to avoid possible security problems (trojan horses, etc). The selected subset of 
QC info is posted by QC host to the merchant site at the 

https://payment.aol.com/order target url page (for future use in creating a confirmation page 
combining order and QC information). Fields from an exemplary form are listed on pgs. 6-7 
of AOL QC Merchant Connectivity Specification, which was filed with provisional 
application number 60/160,874 filed October 22, 1999, which is incorporated by reference in 
its entirety). If the merchant allows multiple shipping destinations for aspects of a single 
order, and the consumer has designated multiple destinations in the information provided by 
the merchant to the host, multiple posts may be made by the host to the 
https://payment.aol.com/order target url page, each post having the same order id number 
but different information where appropriate to accomplish the consumer order. 

After the consumer is redirected to the merchant site, the merchant provides an order 

confirmation page displaying the order and payment data. Specifically, the merchant 

generates a form that displays the selected QC info and that queries the consumer to confirm 

the purchase. The confirmation page posts to a designated location known to wallet host, 

e.g., https://paymentaol.com/confirmorder . Fields from an exemplary form are listed in 

Appendix C (see list of parameters listed on p8 of AOL QC Merchant Connectivity 

Specification). If the merchant allows multiple shipping destinations for aspects of a single 

order, the consumer has designated multiple destinations in the information provided by the 

merchant to the host, and multiple posts are made by the host to the 

https://paymentaoLcom/order target url page with the same order id number, the merchant 

will generate a confirmation page for each part of the order. Generally, information is 
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filtered before being returning to the merchant for confirmation (to prevent merchant from 
obtaining enough financial info to complete transaction until after the complete transaction is 
confirmed by consumer). The merchant then displays screen requesting confirmation of 
shopping cart to selected credit card (with limited information being shown about credit 
card). 

After the order has been confirmed, three processes are performed: 

1 . the customer is redirected to the http://paymentaoLcom/order return url page 
which displays a message from the merchant thanking the customer for their order 

2. the merchant receives complete credit card information from the host along 
with other order information that is posted to target url specified in the order_target_url field 
of the initial post generated by the merchant. This information is used by the merchant to 
deliver the ordered goods. An examplary format for the order information is shown by 
appendix D (see pp8-10 of AOL QC Merchant Connectivity Specification). 

3. the merchant pushes order data to a URL accessible to the wallet host for 
customer service, record keeping and order tracking purposes. 

Using this system, and the ability to store and share personal information, it is 
possible to provide enhanced functionality such as parental controls, AOL rewards, gift 
reminders, purchase history, and keyword billing. 

Furthermore, integration with a service provider enabling several screen-names for a 
single account allows the user to designate separate wallets/passports for different members 
on an account, each drawing on some common and some independent information. For 
instance, several family members having different screen-names may each maintain 
independent wallets with separate e-commerce information while being provided access to a 
shared wallet having shared e-commerce information. In this manner, selected credit cards 
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or e-commerce information may be made accessible to some or all screen-names without 
sharing all credit cards or other e-commerce information. Furthermore, when combined with 
the passport functionality, this model allows information to be maintained and communicated 
for each independent screen-name. 

The techniques, methods, and systems described here may find applicability in any 
computing or processing environment in which electronic content may be viewed, accessed, 
or otherwise manipulated. For instance, the concept of sharing e-commerce transaction 
information between hosts in a networked computing environment could be applied 
whenever those preferences are useful to a third party, such as an e-commerce merchant. One 
such environment involves a computer system (e.g., a Microsoft Windows-based PC or 
Apple Macintosh) that is connected to the Internet. 

Various implementations of the systems and techniques described here may be 
realized in digital electronic circuitry, or in computer hardware, firmware, software, or in 
combinations thereof. A system or other apparatus that uses one or more of the techniques 
and methods described here may be implemented as a computer-readable storage medium, 
configured with a computer program, where the storage medium so configured causes a 
computer system to operate on input and/or generate output in a specific and predefined 
manner. Such a computer system may include one or more programmable processors that 
receive data and instructions from, and transmit data and instructions to, a data storage 
system, and suitable input and output devices. 

Each computer program may be implemented in a high-level procedural or object- 
oriented programming language, or in assembly or machine language if desired; and in any 
case, the language may be a compiled or interpreted language. Suitable processors include, 

by way of example, both general and special purpose microprocessors. 
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Generally, a processor will receive instructions and data from a read-only memory 
and/or a random access memory. Storage devices suitable for tangibly embodying computer 
instructions and data include all forms of non-volatile memory, including semiconductor 
memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks 
such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. 

Any of the foregoing may be supplemented by, or implemented in, specially designed 
ASICs (application specific integrated circuits). 

A number of implementations have been described. Nevertheless, it will be 
understood that various modifications may be made without departing from the spirit and 
scope of the invention. For example, advantageous results still could be achieved if steps of 
the disclosed techniques were performed in a different order and/or if components in the 
disclosed systems were combined in a different manner and/or replaced or supplemented by 
other components. 

In addition, the systems, methods, and techniques described here may be 

implemented in digital electronic circuitry, or in computer hardware, firmware, software, or 

in combinations of them. Apparatus embodying these techniques may include appropriate 

input and output devices, a computer processor, and a computer program product tangibly 

embodied in a machine-readable storage device for execution by a programmable processor. 

A process embodying these techniques may be performed by a programmable processor 

executing a program of instructions to perform desired functions by operating on input data 

and generating appropriate output. The techniques may advantageously be implemented in 

one or more computer programs that are executable on a programmable system including at 

least one programmable processor coupled to receive data and instructions from, and to 

transmit data and instructions to, a data storage system, at least one input device, and at least 
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one output device. Each computer program may be implemented in a high-level procedural 
or object-oriented programming language, or in assembly or machine language if desired; 
and in any case, the language may be a compiled or interpreted language. Suitable 
processors include, by way of example, both general and special purpose microprocessors. 
Generally, a processor will receive instructions and data from a read-only memory and/or a 
random access memory. Storage devices suitable for tangibly embodying computer program 
instructions and data include all forms of non-volatile memory, including by way of example 
semiconductor memory devices, such as Erasable Programmable Read-Only Memory 
(EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash 
memory devices; magnetic disks such as internal hard disks and removable disks; magneto- 
optical disks; and Compact Disc Read-Only Memory (CD-ROM disks). Any of the 
foregoing may be supplemented by, or incorporated in, specially-designed ASICs 
(application-specific integrated circuits). 

Accordingly, other embodiments are within the scope of the following claims. 
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What is claimed is: 

1 . A computer-implemented method for sharing a user's personal 
information with a host computer in a networked computing environment, the method 
comprising: 

gathering personal information from a user of the computer network; 

storing the user's personal information at a first network server; 

receiving at the first network server a request for the user's personal 
information from another network server; 

sending the requested information to the other network server, 

2. The method of claim 1, wherein gathering comprises requesting 
information directly from the user. 

3. The method of claim 1, wherein gathering comprises monitoring user 
activity. 

4. The method of claim 1, wherein gathering comprises soliciting 
information from others. 

5. The method of claim 1, wherein the other network server corresponds 
to a business entity with whom the user is engaged in a transaction. 

6. The method of claim 1, wherein personal information includes one or 
more of the user's name, address, credit card information, telephone numbers, 
facsimile number, e-mail address, employer name, employer address, work telephone 

26 



Docket No.: 06975-062001 

numbers, buying history, travel preferences, food preferences, medical information, 
and personal interests. 

7. The method of claim 1, wherein storing comprises saving the 
information in a database. 

8. The method of claim 1 , wherein the other network server is controlled 
by an e-commerce merchant. 

9. The method of claim 1 , wherein the other network server corresponds 
to a web site. 

10. The method of claim 1, further comprising authenticating the user 
prior to sending the requested information to the other network server. 

1 1 . The method of claim 1 , further comprising authenticating a party 
associated with the other network server prior to sending the requested information to 
the other network server. 

12. The method of claim 10 or 1 1 wherein authenticating comprises 
verifying a username and password. 

13. The method of claim 10 or 1 1 wherein authenticating comprises 
checking a digital certificate. 
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ABSTRACT OF THE DISCLOSURE 

A host-based system for sharing personal information of a network user with the 
resources accessed by that network user. The host-based system generally involves either or 
both of two data stores, referred to as passport and wallet. Passport and wallet are host-based 
collections of routinely requested personal billing, shipping and demographics information 
(hereinafter "personal information"). They may be maintained independently or collectively. 
A user with a populated passport or wallet may choose to pass selected information to web 
sites, automatically or with very little effort, to enable an enhanced browsing experience or to 
assist in the completion of an online transaction. 
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Buyer Reg: Enter your Information 



Enter your "information. 

For your protection, this form is protected by Secure Sockets Layer 
Encryption (SSL). Make sure all fields marked with an * are completed. 



[Enter your billing information 

Enter your name as it appears on your credit card. 

Your address is subject to Address verification to ensure accurate processing. 



4oS 



MS 



4Zo 



1 First Name*: [ 
Last Name*: 
Company: 
r Street 1*: 
Street 2: 
City*: 
State*: 
Phone*: 
Email*: 



initial 



Zip Code' 



«[ 



Shortcut Name for this address: 



Enter an easily remembered name for this address, like 
"Home* or "Mom*. 



Go to the next step 



Card*: 

Card 
Number*: 



(Visa 



^ Expiration*: [08 

Shortcut Name for this card: 



Enter an easily rememoered name for th« card, i.ke "Home 
Visa" or "Corporate". 



v Go to th« next *t«p 



I Enter your ship-to information 

;ss iz^^sss^ - - ™« states on,v - 



https: ^/overlay Js.asp' 



.WCt-psProc^Waccm^OSU^n^S^^s, 7,27 



Buyer Reg: Enter your Information 

P'ease note that orders are available for delivery m the United States oniy 

C Check here if this is the same as billing information and click here to continue. 

ilnitial-i 1 



First Name*: [ 
Last Name*: 



Company: £ 
f Street 1*: [ 
Street 2: [ 
City*: f 
State*: 
Phone: 
Email: 



/ 4oo 



I 



Zip Code 1 



E Set as default ship-to address 

[Enter an easily re 
I "Home" or "Mom" 



Shortcut Name for this address: 



remembered name for this address, like 



"Go to the next step 



kYou're almost done! Xf you like, save your information to use next time. 

We can securely save your information so you can use it whenever you see this symbol: * 
You'll never have to fill out this form again. 



Click a choice 



® Save my information. 



O Continue my purchase without saving my information. 



you wit soli be able to cancel your transaction. 



Copyright 1999 Inktomi Corporation. 



Amazon.com Order Form - page 1 

amazon.com 

Completing Your Order is Easy 



We encourage you to enter your credit card number online (why 
this is safe). However, you also have the option of phoning us jj 
with the number after completing the order form. If you have ij 




any problems or questions, see the bottom of the page for details on our toll-free (800) customer 
support number. ^ 



1. Welcome, 



Please check your e-mail address for accuracy; one small typo and we won't be able to 
communicate with you about your order. 

C first-time customer. (You will be asked t o create a password la ter on.) 

0 I am a returning customer, and my password is I 

Have you forgotten your password? 

2. Select a payment method. 

You will enter complete payment information later in the order form. For now, you just need to 
choose your payment method. 



Please enter your e-mail address: 



. customer@aoi.com 



® credit card (Visa, 
MasterCard, Discover, 
American Express, or JCB 

only) 

( whv this is safe) 



O gift certificate (or gift ° check or money order 

certificate and credit card, or ( why this takes longer) 
balance on account) 

( how this works) 





characters): 



Gift Wrap Services 




ucom/exec/obidos/order2/002-9773565-5008028 



7/26/ 



https://www.amazon. 
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amazon.com 



Completing Your Order 

5# Check your order. 

Please verify that the items and quantities shown below are correct. Put a 0 (zero) m the Quantity 
field to remove a particular item from your order. 

Quantity and Item Information: 



Usually ships in 24 hours 

O Evolutionary Game Theon \ By Jorgen W. Weibull; 
Our Price: S17.50 



6. Credit card information: 

Since we already have a credit card on file for you, you can just click on the button next to it to use it 
for this order 



Cardholder Name 



Card Type Last 5 Digits Expires 



® 



Or enter a new credit card for billing: 

If youYe using a new card, please enter the full credit card number below. ( Wh^tfais is safe.) If 
you prefer to phone in your credit card, enter only the last five digits. After you have submitted 
your order; we'll give you the phone number to call. 



Credit card number: 



Type of credit card: °Visa 0 MasterCard 0 Discover 0 American Express °JCB 
Credit card expiration date (only month and year required) 

Cardholder's name as it appears on the credit card; 
Zip or postal code of the bUUng address for this card 




7. What is your name? 

Your name, if it is different from the name on the credit card: 



8. What shipping option would you like? (Click here for more about shipping options, prices 
and international customs.) 



Shipping Method: 



https://www.amazon 



com/exec/obidoVuse-shippi n g-addr e s S /< B kik S o/002-9773565-5008028 7/26/99 



Amazon.com Order Form - page 2 



Page I of Z 



Please note: Total delivery time equals item availability plus shipping time. 



® Standard Shipping (3-7 business days) 
O Second Day Air (2 business days) 
q Next Day Air (1 business day) 

Please note: we cannot ship Second Day or Next Day Air to P.O. Boxes, APO/FPO addresses, and 
addresses served by the USPS as domestic destinations, including Guam and the U.S. Virgin Islands 

Number of Shipments: 

® Make one shipment when complete order is ready (minimizes shipping cost) 
c Ship as ordered items become available (at extra shippi ng cos t) 



Press this button to 




The next page shows you a summary of your order including its total cost. You may then submit 
your completed order or back up and make changes. 

Copyright and di sclaim er © 1996-1999, Amazpa.com. Inc. 
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Request Purchase Information 
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Request Payment Information 



Place Order 
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